Full Code Review for Open Source Approval#11
Conversation
fix bad import path
split into two packages using lerna for management
Hkasemir/circleci
move constants out of shared folder
dcwither
left a comment
There was a problem hiding this comment.
Everything overall looks good. There's one babel thing to double check since IIRC not all browsers support Object.assign, and a few minor suggestions that might be worth responding to before merge, and another few longer term suggestions that definitely shouldn't delay release.
| Copyright 2018 Udacity | ||
|
|
||
| Copyright (c) 2018 Dineshkumar Pandiyan <flexdinesh@gmail.com> | ||
| Licensed under the Apache License, Version 2.0 (the "License"); |
There was a problem hiding this comment.
Is this what we want all our work licensed under? I'm kinda curious why not MIT - though they're both very permissive
There was a problem hiding this comment.
ultimately we decided to use this because it is what the base fluent package is licensed under, and so it made sense to use the same one since they will be used together.
| { | ||
| "env": { | ||
| "development": { | ||
| "presets": ["env", "react", "es2015"], |
There was a problem hiding this comment.
shouldn't need es2015 along side env afaik
| <Localized id='NotAuthorized_oopsMessage'> | ||
| <h1> | ||
| {/* here is a comment for the localizer */} | ||
| Oops! looks like you're not authorized to use this app. |
| <div className="container"> | ||
| <Loc.H1 l10nId="NotAuthorized_oopsMessage"> | ||
| {/* here is a comment for the localizer */} | ||
| Oops! looks like you're not authorized to use this app. |
| `l10nJsx` props. | ||
|
|
||
|
|
||
| ### `augmentLoc(customElements)` |
There was a problem hiding this comment.
AFAICT this isn't exactly an "augmentation" since it's returning something new. On the one hand, it's just as easy for someone to do {...Loc, MyButton: MyLocalizedButton}, it is good for communicating how to use it.
I think it would be helpful to add to the docs that this operation is pure
| export function NotAuthorized() { | ||
| return ( | ||
| <div className="container"> | ||
| <T.H1 l10nId="NotAuthorized_oopsMessage"> |
There was a problem hiding this comment.
Is this demonstrating the localization of a different prefix? Maybe to encourage best practices we should avoid single letter names?
| const varNames = Object.keys(l10nVars); | ||
|
|
||
| return varNames.reduce( | ||
| (vars, name) => Object.assign({}, vars, { [`$${name}`]: l10nVars[name] }), |
There was a problem hiding this comment.
- can you make sure that the babelrc setup compiles this down to include the polyfill (but not in the global manner that
@babel/polyfilldoes?
https://babeljs.io/docs/en/babel-plugin-transform-runtime I think is the transform to use.
There was a problem hiding this comment.
Why not just use spreads here?
(vars, name) => {...vars, [`$${name}`]: l10nVars[name] },| @@ -0,0 +1,80 @@ | |||
| import React from 'react'; | |||
There was a problem hiding this comment.
Suggestion to keep the tests in the same folders as the things they're testing. I've come to prefer that, and I think services team does as well. @hitchcockwill?
| // modified from https://searchfox.org/mozilla-central/source/intl/l10n/L10nRegistry.jsm | ||
| // removed option for 'flipped' to test RTL | ||
|
|
||
| const ACCENTED_MAP = { |
There was a problem hiding this comment.
Does this end up in live code? Should we ensure it doesn't?
There was a problem hiding this comment.
That would be at the discretion of projects using this package to determine how they set up the string transformation settings to use pseudolocalization, and whether it is accessible in live environments or not.
| } | ||
|
|
||
| function getEntryName(entry = {}) { | ||
| if (entry.id) { |
There was a problem hiding this comment.
- is it possible to entry to be null? that wouldn't be caught by the
entry = {}
Same with the above functions. Typescript could help our confidence here.
hitchcockwill
left a comment
There was a problem hiding this comment.
I can take a little deeper dive later this week. One thing that would be good to work on is better test coverage for the extractions package. There are a ton of small units of code there that could be easily tested but don't have coverage right now.
| import { STANDARD_ELEMENT_TYPES } from './constants'; | ||
|
|
||
| export const Loc = { | ||
| A: makeLocalizedElement('a'), |
There was a problem hiding this comment.
What's the reason for capitalizing these? Why not match the actual element name exactly?
There was a problem hiding this comment.
Interesting idea!
My reasoning for the capitalization was to make clear that it is a React component, and not just the basic html element. I think if we figure out a clear way to resolve this issue #9, then having the capitals will be particularly beneficial to understand that it's different. If we don't, I could see the argument for lowercase, since it would just be <Loc.a>. Though l still feel like it goes against React best practices
| const varNames = Object.keys(l10nVars); | ||
|
|
||
| return varNames.reduce( | ||
| (vars, name) => Object.assign({}, vars, { [`$${name}`]: l10nVars[name] }), |
There was a problem hiding this comment.
Why not just use spreads here?
(vars, name) => {...vars, [`$${name}`]: l10nVars[name] },| "babel-preset-es2015": "^6.24.1", | ||
| "babel-preset-minify": "^0.3.0", | ||
| "babel-preset-react": "^6.24.1", | ||
| "chai": "^4.1.2", |
There was a problem hiding this comment.
Is there any particular reason for using chai and mocha for testing? Why not jest?
| "test:prod": "cross-env BABEL_ENV=production npm run test", | ||
| "test:only": "mocha --require babel-core/register --require babel-polyfill --recursive", | ||
| "cover": "istanbul cover _mocha -- --require babel-core/register --require babel-polyfill --recursive", | ||
| "lint": "eslint src test", |
| @@ -0,0 +1,18 @@ | |||
| { | |||
There was a problem hiding this comment.
Do we need to have separate .babelrc and .eslintrc files for each package? Is there any way to have a single of each rc file at the root level?
To be able to officially run through the code and ensure quality and cleanliness of code - that we are not exposing any proprietary information.